Methods of processing a request associated with a user from a requesting node to an answering node in a network are known, and may require information relating to the user, e.g. stored in a user profile associated with the user, to be retrieved by the answering node, e.g. for determining how the request is to be treated. It is for instance possible that the information relating to the user determines how the request is treated, a service level of the request, an authorization level of the request, etc.
One such known method is used in an Internet Protocol (IP) Multimedia Subsystem (IMS) telecommunications network. Several entities in the IMS network may have to perform a database search, when processing for instance a session initiation protocol (SIP) session establishment request. Examples of such entities include a Proxy Call Session Control Function (P-CSCF) entity, a Serving Call Session Control Function (S-CSCF) entity and a Session Initiation Protocol Application Server (SIP-AS).
Examples where such entities need to perform a database search are:
(1) When an IMS user establishes a call (i.e. establishes a SIP session), the S-CSCF entity receives a SIP Invite from the P-CSCF or I-CSCF entity; the SIP Invite contains the P-Asserted-Identity (PAI) header. The PAI header identifies the calling subscriber. The S-CSCF entity uses the PAI as criterion to search its internal database of registered subscribers, in order to obtain the user profile of this subscriber.
(2) When a call is established towards an IMS subscriber (i.e. a SIP session is established), the S-CSCF entity receives a SIP Invite from an I-CSCF entity; the SIP Invite contains a Request Uniform Resource Identifier (R-URI). The R-URI identifies the called subscriber. The S-CSCF entity uses the R-URI as criterion to search its internal database of registered subscribers, in order to obtain the user profile of this subscriber.
(3) When a call is established towards an IMS subscriber, then the P-CSCF entity serving that subscriber receives a SIP Invite from the S-CSCF entity. The P-CSCF entity uses the Contact address, contained in the R-URI in the SIP Invite or the P-Called-User header, as criterion to search its internal database of registered subscribers, in order to obtain the user profile of this subscriber.
(4) When a SIP-AS processes a service invocation request, then the SIP Invite sent to this SIP-AS contains a PAI and/or R-URI. When the SIP Invite relates to an originating SIP session establishment, then the SIP-AS uses the PAI as criterion to search its internal database of provisioned and registered subscribers, in order to obtain the user profile of this subscriber. When the SIP Invite relates to a terminating SIP session establishment, then the SIP-AS uses the R-URI as criterion to search its internal database of provisioned and registered subscribers, in order to obtain the user profile of this subscriber.
When an IMS network (e.g. ims.provider.com) supports only public SIP-URI's, i.e. IMS Public User Identities (IMPU), belonging to its own domain (e.g. sip: user_1234 @ ims.provider.com), nodes in that network, such as P-CSCF entity or S-CSCF entity, can use the user-part of these SIP URI's (e.g. user_1234) as search key to find information on that subscriber, i.e. find a match in its internal subscriber record.
When an IMS network also allows other public SIP-URIs (e.g. sip:jos.den.hartog @ ericsson.com), the home subscriber server (HSS) (and S-CSCF entity and P-CSCF entity) must use this complete string (i.e. user @ domain) as search key for the subscriber.
One problem in the above examples, but also in other methods of processing a request associated with a user from a requesting node to an answering node in a network in general, is that searching a database, e.g. a database of registered subscribers, may take some time. If treating the request requires the retrieval of information from the database as described above, then this may cause delay in processing the request.